What is the use case really? It seems kind of bad because the hostname/protocol shouldn't be an important part of the app (it's really just a deployment detail). Just my opinion though :>

@caitp See the referenced case for the use case, where you commented on this same issue previously.

It's a common use case in an application to prompt the user when a route change is detected with the current page editing a dirty record.

This isn't a real use case though, the current design doesn't prevent this from happening. No use case is provided for changing the app location using the full URL

I can assure you it's a real (and real common) use case. I must be missing something. You seemed to agree with this before, now you seem to disagree. What am I missing?

It's a fact that the very url the event provides is not usable to continue navigation so there's a fundamental issue here no matter the use case.

I never said I agree that it's a good use case, I said it's kind of annoying that we don't let you set an absolute URL --- but there are good reasons for this. Anyways, the decision on whether to include this in the framework isn't up to me really, however I can think of good reasons why we wouldn't want to support that.

Interesting, I feel that you might not fully understand what is going on here or have a skewed view of it that I can't quite fathom.

I view it as a straightforward inconsistency and design mistake in implementing the API, but I have a workaround and more pressing issues to attend to, so I'll leave it to the collective wisdom of the crowd.

I feel that you might not fully understand what is going on here or have a skewed view of it that I can't quite fathom.

I assure you, I understand what you're trying to do --- but one should not be specifying full urls here, it just doesn't make any sense (in my opinion). There are other workarounds, like replacing the application base url with the empty string in the event handler.

I think that is probably a much better (safer) solution to this problem than what is implemented currently in this PR.

@caitp hostname and protocol is used :

1. Only to ensure that we change path for the full URL which pertains to the current app.
2. We don't replace code path for the normal "/user/app" cases.

Why i am not checking if this is just the full path with hostname ?
Since path function is used to navigate inside the same website. So i only want to address the full paths within the same application. the hostname is identification of location not going outside the app and can be handeled by the $location.path(). hence used to identify the cases we can handle in this way.

It will be good to navigate using the full url in the $location.path().

@caitp You mentioned other work around will be to replace the application base url with empty string. are you mentioning to event handler for the event locationChangeStart.

sorry i am quite new to angular if i am missing something. in solution you proposed

Just to understand the solution, we only have access to event object, newUrl and oldUrl.

are you proposing to create a new Location object and pass the empty string in appBaseUrl and then use $location.$$parse to get the path in event handler. but how this will navigate to the correct location since parse use the appBase url to get path . As we are setting it to empty string it won't be able to get the correct parsing as i see in the code.

There is some method in event object and it does the parsing properly.
I guess if we have to get the path out of the full url we need to have the correct application base url . i don't seem to understand how we will get the application path from full url by making application base url as empty.

Thanks for commenting and reviewing the PR 👍

I'm saying the path() routine could replace the appBase with the empty string, if found --- because that is the only full url that should ever be used